デブサミ2016レポート「今日の習慣が明日をつくる～よりよい技術者を目指して～」

#イベント

虎塚

2016.02.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、虎塚です。

Developers Summit 2016でセッション【19-C-3】「今日の習慣が明日をつくる～よりよい技術者を目指して～」を聴講したのでレポートします。佐藤太一さんが講演されました。

発表資料

セッション概要

発表者が習慣的に行っているエンジニアとしての訓練のうち、明文化できるもの、価値があると思われるものを整理して伝える。このセッションの目標は、「技術者としての習慣を見直すきっかけを提供すること」。自分にマッチするものを見つけて習慣に取りいれ、皆でよい技術者になろう。

よい技術者とは？

このセッションでは、読む力、書く力、捨てる力の3つが高い技術者を「よい技術者」と定義する。

読む力とは

仕様を読む力
- 書かれていることを読み取る力だけでなく、仕様に書かれていない暗黙の前提条件や仮定を適切に理解する力を含む
より少ない時間でたくさんのコードを把握する能力
- 関数やオブジェクトの関係性を把握
評価する能力
- 他人が作ったものや過去自分が作ってきたものについて、設計や品質の妥当性を検証する能力

書く力とは

仕様に対して妥当なアルゴリズムを実装する基本の能力
書いたコードの制約を明らかにすること
- 仕様に書かれていなくて類推した部分
- 使っているプログラミング言語やプラットフォームによる制約
書いたコードの最低限の品質をテストによって保証する能力
- なぜ品質を保証するときっぱり言わないかというと、QAは独立した能力と考えるため。しかし、QAがテストを開始できるだけの品質を提供する能力は必要
- 結合テストくらいまではデベロパーの担当範囲と考える。その範囲ですべてのエッジケースを潰せることは想定しない。もちろん、デベロパーがそれをできるに越したことはない。

捨てる力とは

現在のコードを作り直す能力
- 人は古いコードを見るとやり直したくなるが、本当にそれができるかは能力に依存する
- 多くの場合、捨ててやり直すことはそれほど簡単ではない
- 価値を持って動いているシステムを簡単に捨てることはできない
- 捨てる訓練が必要
現在のコードを厳密に再定義する能力
- レガシーコードは、テストがなかったり仕様書がなかったりと仕様に不明確な部分が多い
- それでもソースコードを読んで現在の仕様を再定義できる能力
同じ仕様をさまざまな方法で表現する能力
- 仕様に対する実装は1つではない。パラダイムやアーキテクチャが違うさまざまな実装が提供できるはず
日々成長しているなら過去のコードは捨てられるようになる。また、コードを捨てることで成長実感を得る

よい技術者になる方法

結論: 仕様書とコードを大量に読んで、書いて、捨てる。ショートカットはない。

仕様書を読む習慣

標準化された仕様書をごく当たり前のように読む習慣をつけよう。

ISO、IEEE、IETFのRFC、W3C、WHATWG、JavaプログラマならJEP、JCPのJSRなど、自分の業務領域に近い標準化団体をウォッチしよう。

仕様書を読むことの意味

標準化された仕様書は、高度な技量のある技術者が集まって議論した成果なので、高度に整理された知見がつまっている。そこから都合のよい箇所だけを拾う
- たとえば、ISOの標準化資料は全部入り。ロケットを飛ばすようなプロジェクトにも適用できる網羅性を持つ。そこから自分のプロジェクトにあわせて引き算する。
- 自分でゼロから作るのは大変だが、ちょっとだけ削除したり変更したりするのは簡単。標準化資料がどこにあるかと、どう読むかを知っていればよい
技術の原理原則を理解するため
- エンジニアリングの根幹
- ワークアラウンドする前に仕様を確認する
- 仕様を理解した上で、自分たちの都合のよいようにワークアラウンドするのはよいが、原理原則を理解せずに「とりあえずこれで動くから」とワークアラウンドをするのは最悪
アプリやミドルが正しく動いているかを検証するため
- 現代的なアプリは、仕様が広く公開されていることを前提としているものを使って実装されている
- 公開されたフェアな仕様に則らない製品を回避する
- (例) 昔のInternet Explorerはインターネットの標準とかけはなれた動作をしていた

どの仕様書を読むか

まずHTMLから

巨大な仕様なので、すべて通して読む必要はない。日常でHTMLの要素や属性についてわからないことがあれば、適当に検索する前にW3CやWHATWGの仕様書を確認しよう
仕様書特有の言い回しや分かりづらさには慣れるしかない
- とはいえ、動作するものが正義という団体なので、ほかの仕様書とくらべると読むのがそれほどつらくない

RFCなら2119から

RFC2119 (Key words for use in RFCs to Indicate Requirement Levels) では、「MUST」や「SHOULD」などRFCの要求の程度を示す表現について定義している。

ふだん自分で仕様書を書く時にも、要求の程度の表現について意識し、「やるべきこと」と「やることが望ましいこと」を区別して書くことが望ましい。要求の程度についての表現が一貫していると、読みやすい仕様書になる。

RFCの本命はHTTP1.1

RFC2119の次に、RFC7231 (Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content) を開始点として読んでいく
- （本セッションの会場にいる）多くの人はなんらかの形でWebに関わるシステムの開発をしているはず
- 最先端のHTTP2はHTTP1.1を完全に前提にしているので、まずHTTP1.1から理解する
- RFC7231では、HTTPのステータスコードやheaderの意味を説明している
- たとえば、RESTfulなアプリでどんなステータスコードを返せばよいかよくわからない、という時に読む
おすすめの読み方
- 流し読みしてボリューム感を掴む。1週間や2週間では無理なので、挫折しないようにゆっくりと
- 何度も流し読みして徐々に慣れること
- より古いRFCへのポインタがあるので、それをたどっていくことで理解できる
- 最終的にDNS (RFC1035) やURI (RFC3986) にたどりつく。それらを総合的に理解することがインターネットを理解することにつながる

読んでほしいJSR

発表者がJavaエンジニアなので、おすすめのJSRを挙げる。

Java Transaction API
Java Servlet 2.4
- すこし古めのServlet仕様。ほかのWebフレームワークでも参考にしているものがおおい
Java Servlet 3.1
- WebSocketなど最先端の技術にいち早く取り組んだJSR。

論文と仕様書ならIEEE

IEEE 754-2008 (参照: IEEE 754: Standard for Binary Floating-Point Arithmetic)
- 浮動小数点演算に関する仕様
- たとえば、Javaで浮動小数点の計算をしたら負けというが、なぜ負けなのかがこれを読めばわかる

網羅性が気になったらISO

自分の開発のやり方は正しいのか。作成しているドキュメントに不足はないか。プロジェクトがうまく回っていないが、何が足りないかわからない。プラクティスを取り入れてみたが、多すぎたり少なすぎたり、形骸化したりする……といった悩みに直面したら、ISOの仕様書にあたる。

網羅性の高い仕様にあたり、不要なものを削って、よさそうなものだけを拾う
- ISOの仕様書は、内部が細かく分かれていてモジュール性をもっている。一部だけ取り出してプロセスをモデリングしやすい作り
おすすめのISO仕様書
- ISO 12207: ソフトウェアライフサイクル全般
- ISO 90003: ソフトウェアの品質保証

まとめ: 議論の起点は仕様書であるべきなので、仕様書を読もう。よい技術者は仕様書をよく確認している。

コードを読む習慣

Githubには成長の機会がある
- 大量のよいコードがある（悪いコードもある）
貢献の機会がある
OSSなら無償でリポジトリを公開できる
- 公開状態で作業するならタダで使わせてくれる

毎日ログインしよう

毎日5分Trending repositories on GitHub todayを見よう
どんな言語が流行り、開発者が注目されているかを見る
最初はリポジトリまで見なくてもいい。惰性でトレンドを見る習慣をつけるのが大事
言語を絞らずにトレンドに上がるリポジトリを見てみると、誰かが学習成果を公開しているリポジトリが多い
だれかがムリのないやり方で続けて、上手くいったものを、皆が見にいっていることがわかる
Gituhub以外の情報源としては、Techblogがおすすめ
Voxxed

毎日30分コードを眺めよう

理解しなくていいので、トレンドに上がってくるリポジトリを開発言語で食わず嫌いせずに眺めよう。

コードを眺めるとは

絵画的に鑑賞する（CSSのblurがかかっているような状態をイメージ）
- キーワードとそうでないものを色で区別する程度に
- 単語は見ない
- インデントは見る
- (例) コメントがあるとか、ほかのモジュールへの依存性があるとか、ネストが深いが規則性ある、とか

なぜ眺めるのか

知らないものへの恐れを減らすため
- 意識しないレベルで見たことがあるものを脳に記録するため
将来たくさんコードを読んでいくための準備
- 既視感のあるものは挫折しづらい
よい処理構造はあまり言語に関係ない

コードを見慣れよう

モチベーションなしにコードを見られるようになろう
- 呼吸するたびに意識を高めたりはしないよねと
気がついたら眺めている状態を目指す

読むべきリポジトリ

得意言語で書かれているもの
リポジトリの説明がわかりやすいもの
Readmeに目的や価値、ビルド方法、使い方が書いてあるもの
半年以内のコミットがあるもの
CIサービスと連携していて、成功が維持されているもの
- CIがコケている場合、リポジトリが荒れていて、学べるものの量がすくない可能性がある

コードの読みはじめかた

依存ライブラリを確認する
- 知らないライブラリがあれば、そちらを優先して読んだほうが、すぐに役立つことが多い
ビルドする
ユニットテストを実行する
エディタやIDEは慣れたものを使う

コードの読み方

リポジトリ内のすべてのコードを何度も眺める
- 15〜30分区切りでどんどん読む
広く浅くさまざまな部分をぼんやり覚えている状態を目指す
main関数やアプリケーション呼び出し箇所など、外部との境界面から読む
仮説と検証を繰り返しながら読むことで、記憶に定着しやすくなる
抽象度の高い部分を優先して理解する
- ヘッダファイルやインタフェース、抽象クラスなどのコンストラクトから読む
むずかしい部分はエディタでブックマークして後回しにする
コードが荒れている箇所は、git blameすると、書いた人たちの苦労を眺めることができる
UMLのような絵を使うと分かりやすい
デバッガを使うと動作をより正確に把握できる。ただし、状況が固定されるかもしれない

まとめ: コードは高速に読もう。毎日読むなら、ほかのことができるように、速く読めたほうがよい。読む速度は改善できる。

コードを書く習慣

年をとるとコードを書けなくなる？
SI系企業では実装工程をおこなう技術者への評価は残念ながら低めであることが多い
30代中盤にもなるとリーダーシップを期待される
規模のある組織としては、若手が育つこともミドルマネジメントも重要

このような背景もあり、かならずしも仕事でコードを書けるとはかぎらない。そこで、一人砂場プロジェクトをしよう。

一人砂場プロジェクトをしよう

一人でコードを書き、学ぶ遊び。自分で全部やる。誰にもまかせない
仕事ではないので計画しない、リスクコントロールしない、やりたいときだけやる、飽きたらやめる
書いたコードは公開しなくてもいい
- でも公開したほうがよい。恥ずかしいかもしれないが、どうせ誰もまったく見ていないので大丈夫

一人砂場プロジェクトをする意味

しがらみのない自由を味わうため
自分の能力を後で客観的に評価できる。1年前にどうだったかがシビアにわかる
価値観を少しずつ変えるため
価値の不明瞭なものを評価するため
- (例) オブジェクト指向、関数型ときて、次はどんな新しいパラダイムがくるのか
- 一人砂場プロジェクトでそういったものを試しておくと、仕事で新しいパラダイムに安全に移行できる

一人砂場プロジェクトで何をするか

よさそうなものを何でも使ってみる
- 言語、ライブラリ、フレームワーク、CIサービス、PaaS
今使っている道具を点検する
- もっと便利なエディタはないか、もっと速いビルドツールはないか

何か作りたいけどネタがない人へのおすすめ

短縮URLを生成する画面のないサーバ
- postボディにURLつけてリクエストするとレスポンスボディに短縮済みのurlをかえす
ブログサーバ railsチュートリアル
ファイルアップローダ

小さい車輪を再発明しよう

ほかの言語にあるけど得意言語にはないものを実装する
- たとえばxUnitはそのようにして多くの言語に輸出されてきた
- 最近は新しい言語が出るとRSpecモドキがどんどん出る
- (例) taichi/siden: tiny web application framework for Java SE 8 on top of undertow.は、Java8でNodeのExpressモドキを実現しようとした

毎日すこしずつ書こう

最初はエディタを起動して新しいプラグイン入れるだけでいい
数百行かけたらしめたもの
楽しくやろう！

捨てる習慣

どんどんコードを書いてくと、やがて「もうだめだ、捨てよう!!」という最高の瞬間が訪れる。

毎日書いていれば、半年くらいで大きなコードベースになる
そこでやり直せれば大きく成長できる
はじめから終わりまでを何度も繰り返す
- よい技術者は同じ仕様で何度もコードを書いている

まとめ

よい技術者になるには、仕様書とコードを大量に読んで、書いて、捨てること。無理をせずにやっていきましょう。

おわりに

最初に「明文化できる習慣を紹介する」と述べられていたとおり、小さくはじめる具体的な話がたくさんあり、これなら自分にもできるのではないかと思わせられる、素晴らしいセッションでした。セッションタイトルの「今日の習慣が明日をつくる」はそのとおりで、緊急度は低いけれども大事なことを、つい後回しにしがちですが、むりせず習慣として回していきたいと思いました。

私事ですが、発表者の佐藤さんが数年前に公開された「太一のコードの読み方メモ」を参考に、JVMコードリーディングをしたことがあり、今回はどんなお話が聞けるのだろうと楽しみに参加しました。今回のセッションでは省略された「仕様書を書く習慣」や「他人や自分が書いたものを評価する力」のつけ方についても、いつかどこかで聴けるとうれしいです。

それでは、また。